Skip to content

[11.x] Minor Feature a Prohibited If Declined and Prohibited If Accepted validation rules #54439

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

osama-98
Copy link
Contributor

@osama-98 osama-98 commented Feb 2, 2025

Adding a new simple validation rules that are useful for prohibiting attributes if other attribute's value is declined or accepted, in many cases I was setting the exact value to prohibit another attribute and in most cases it has a workaround to achieve the needed validation, please see the below example to understand this change:

Before: for prohibited_if_declined

"free_delivery_fees" => "bail|required",

// this rule only covers the "false" exact value
"delivery_fees" => "prohibited_if:free_delivery_fees,false|numeric|min:1|max:9999",

// this rule only covers the "0" exact value
"delivery_fees" => "prohibited_if:free_delivery_fees,0|numeric|min:1|max:9999",

// And more for all falsy values

After: for prohibited_if_declined

"free_delivery_fees" => "bail|required",
"delivery_fees" => "prohibited_if_declined:free_delivery_fees|numeric|min:1|max:9999",

Before: for prohibited_if_accepted

"discount_disabled" => "bail|required",

// this rule only covers the "true" exact value
"discount" => "prohibited_if:discount_disabled,true|numeric|min:1|max:9999",

// this rule only covers the "1" exact value
"discount" => "prohibited_if:discount_disabled,1|numeric|min:1|max:9999",

// And more for all truthy values

After: for prohibited_if_accepted

"discount_disabled" => "bail|required",
"discount" => "prohibited_if_accepted:discount_disabled|numeric|min:1|max:9999",

@taylorotwell
Copy link
Member

I am closing this pull request because it lacks sufficient explanation, tests, or both. It is difficult for us to merge pull requests without these things because the change may introduce breaking changes to the framework.

Feel free to re-submit your change with a thorough explanation of the feature and tests - integration tests are preferred over unit tests. Please include it's benefit to end users; the reasons it does not break any existing features; how it makes building web applications easier, etc.

Thanks!

@shaedrich
Copy link
Contributor

@osama-98 Maybe, you find laravel-working-group/laravel-form-requests-improved helpful then :)

@osama-98
Copy link
Contributor Author

osama-98 commented Feb 5, 2025

@taylorotwell
Thanks for your review and comment, I'll for sure try again with more explaination and test cases 🫡🫡

@dcgitx
Copy link

dcgitx commented Feb 12, 2025

@osama-98 Maybe, you find laravel-working-group/laravel-form-requests-improved helpful then :)

I would say the scenarios mentioned (in the PR) are already covered in the framework docs from here onwards https://laravel.com/docs/11.x/validation#rule-required-if

@osama-98
Copy link
Contributor Author

osama-98 commented Feb 13, 2025

@osama-98 Maybe, you find laravel-working-group/laravel-form-requests-improved helpful then :)

I would say the scenarios mentioned (in the PR) are already covered in the framework docs from here onwards https://laravel.com/docs/11.x/validation#rule-required-if

@dcgitx

The difference between "prohibited" and "required" can be subtle, especially when you need to prevent certain data from being passed based on the value of another key. This PR addresses that by introducing conditions where specific keys are prohibited depending on whether another key’s value is accepted or declined.


prohibited_if_accepted

This rule prevents the discount key from being included if the discount_disabled key has a value that indicates "accepted" (i.e., the discount is effectively turned off). For example, if discount_disabled is one of the following values: ['yes', 'on', '1', 1, true, 'true'], the discount key will be prohibited.

"discount_disabled" => "required",
"discount" => "prohibited_if_accepted:discount_disabled",

// Currently to achieve this you need to chose one value from accepted values as below:
"discount" => "prohibited_if:discount_disabled,1",
// Or
"discount" => "prohibited_if:discount_disabled,TRUE",
// Or
"discount" => "prohibited_if:discount_disabled,ON", // this can be used for radio buttons for example
// Or
"discount" => "prohibited_if:discount_disabled,YES",

prohibited_if_declined

On the other hand, this rule prohibits the discount key if the discount_enabled key has a value that indicates "declined" (i.e., the discount is off). If discount_enabled is one of the following values: ['no', 'off', '0', 0, false, 'false'], the discount key will be prohibited.

"discount_enabled" => "required",
"discount" => "prohibited_if_declined:discount_enabled",

// Currently to achieve this you need to chose one value from accepted values as below:
"discount" => "prohibited_if:discount_enabled,0",
// Or
"discount" => "prohibited_if:discount_enabled,FALSE",
// Or
"discount" => "prohibited_if:discount_enabled,OFF", // this can be used for radio buttons for example
// Or
"discount" => "prohibited_if:discount_enabled,NO",

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants